Saltar al contenido principal

Risks-Analysis

Seguimiento de riesgos​

SPRINT 3. Semana del 02/04 al 22/04:​

Durante esta semana el equipo ha detectado que se han activado los siguientes riesgos y se han aplicado los correspondientes planes de contingencia:

  • Problemas de coordinación entre miembros

    • Activación del riesgo: el riesgo se activó el día 05/04 tras darse cuenta algunos miembros que sin querer habían realizado la tarea de otra persona ya que tenían asociada una tarea general que englobaba a otras.
    • Planes de contingencia aplicados:
      • Mejorar la comunicación entre miembros y mediar la situación. Tras detectar el problema los miembos afectados dialogaron sobre la situación para determinar qué hacer con las tareas o si hacía falta una reasignación.
      • Reasignación de tareas. Tras dialogar, algunos integrantes decidieron que lo mejor era cambiar la tarea que había sido realizada por otro y que el que la había realizado sin querer le ofreciera otra de dificultad similar. En caso de no tener tareas equitativas en cuanto a carga de peso, los integrantes llegaron a un concenso.
    • Estado actual: mitigado (11/04). Los grupos tuvieron reuniones para organizarse y los integrantes comunicaron sus inquietudes y problemas para realizar las tareas, llegando a soluciones como que las personas que ya no tuvieran nada que hacer se llevaran tareas de otras personas que tenían gran carga de trabajo y se avanzó en el trabajo que estaba pendiente.
    • Lecciones aprendidas: con el diálogo cualquier adversidad se puede solventar. Cuando se trabaja en un proyecto software y no se tiene mucha experiencia planificando, es común que alguna persona acabe abarcando un mayor alcance con su tarea de lo que debería, ya que esta podría no haber sido bien definida y limitada.
    • Eficiencia de los planes de contingencia: en este caso, funcionó correctamente, ya que aquellos miembros se sintieron más aliviados al tener menor carga y las tareas avanzaron más rápidamente. Asimismo, se vuelve a reiterar que la comunicación es esencial, ya que solventa muchos problemas.

  • Dependencias de tareas

    • Activación del riesgo: el riesgo se activó el día 08/04, cuando el equipo se dio cuenta de que habían personas que no podían avanzar en sus tareas de desarrollo debido a fallos de algunas implementaciones o a retrasos en tareas necesarias para comprobar el funcionamiento de la que estaban haciendo.
    • Planes de contingencia aplicados:
      • Ayuda por parte de otros miembros al miembro con la tarea frenadora. Si la causa por la que la tarea no puede ser finalizada es porque la persona asignada a esta tiene complicaciones para completarla, otro miembro que tenga menor carga de tareas o que haya finalizado las suyas le ayudará para que puedan avanzar.
      • Avance y preparación del cambio por parte del miembro con la tarea en pausa. Mientras se soluciona la causa por la que la tarea está siendo frenada, el integrante que no pueda completar su funcionalidad, debe avanzar todo lo posible para dejar la tarea casi para comprobar si funciona una vez todo esté integrado. Una vez la tarea frenadora se solvente, seguirá trabajando de manera normal.
    • Estado actual: mitigado (21/04). El equipo ha finalizado las tareas atrasantes y otros integrantes han podido continuar con las tareas restantes.
    • Lecciones aprendidas: siempre se puede adelantar trabajo aunque no se pueda terminar por circunstancias externas. Las dependencias entre tareas surgen cuando el equipo es inexperto y tiene dudas o se queda atascado y no termina de planificar correctamente. Conforme más experiencia se adquiere, menos problemas de dependencias de tareas se tienen.
    • Eficiencia de los planes de contingencia: los planes de contingencia en sí han sido útiles, sin embargo, no han podido mitigar el riesgo antes de lo que lo ha realizado. No obstante, la causa real ha sido debido a que con la festividad, el equipo se ha desentendido un poco del proyecto.

  • Repartición desequilibrada de tareas

    • Activación del riesgo: el riesgo se activó el día 06/04, cuando el equipo se dio cuenta de que habían personas que ya habían terminado todas las tareas que tenían asignadas para este Sprint y otras todavían tenían varias pendientes. También se pudo comprobar cuando, al registrar las horas necesarias, habían personas que no llegaban a las 10 horas mínimas y otras se pasaban de estas.
    • Planes de contingencia aplicados:
      • Ayuda por parte de miembros con menor carga de tareas. Aquellas personas que hayan terminado sus tareas rápidamente o que tuvieran pocas tareas que hacer para este entregable debe ayudar a otra persona que tenga mayor carga para agilizar la finalización de las tareas a realizar.
    • Estado actual: mitigado (12/04). Se solventó tras haber realizado una reunión de seguimiento del equipo para revisar el estado de las tareas y la carga de trabajo de los miembros. Se hizo un reparto de tareas para aquellos que tuvieran pocas tareas o ninguna, rebajándose la carga que tenían otros miembros con más tareas.
    • Lecciones aprendidas: las tareas entre pares se realizan más velozmente que de manera individual. Si no terminas las tareas de un sprint anterior se acumulan y cuando no se puede posponer más es cuando más carga tiene uno. Es buena práctica cambiar la asignación de tareas cuando la situación lo requiera, pues ayuda a que algunos miembros no se fatiguen y desmotiven con el proyecto. Además siempre es aconsejable tener más de una opinión sobre algo que se está haciendo.
    • Eficiencia de los planes de contingencia: nuevamente, funcionó correctamente, ya que aquellos miembros se sintieron más aliviados al tener menor carga y las tareas avanzaron algo más rápido.

  • Retraso en algunas tareas

    • Activación del riesgo: el riesgo se activó el día 06/04, cuando el equipo se dio cuenta de que habían personas que ya habían terminado todas las tareas que tenían asignadas para este Sprint y otras todavían tenían varias pendientes. También se pudo comprobar cuando, al registrar las horas necesarias, habían personas que no llegaban a las 10 horas mínimas y otras se pasaban de estas.
    • Planes de contingencia aplicados:
      • Ayuda por parte de miembros con menor carga de tareas. Aquellas personas que hayan terminado sus tareas rápidamente o que tuvieran pocas tareas que hacer para este entregable debe ayudar a otra persona que tenga mayor carga para agilizar la finalización de las tareas a realizar.
      • Reducción del alcance. Para poder salvar el proyecto, en caso extremo, se pueden prescindir de las tareas no esenciales para poder realizar una entrega dentro del plazo establecido.
    • Estado actual: mitigado (21/04). El equipo ha finalizado las tareas que quedaban pendientes para el entregable.
    • Lecciones aprendidas: las tareas entre pares se realizan más velozmente que de manera individual. Si no terminas las tareas de un sprint anterior se acumulan y cuando no se puede posponer más es cuando más carga tiene uno.
    • Eficiencia de los planes de contingencia: para este caso, el plan de contingencia no ha funcionado. Esto se ha debido no porque no haya sido una buena alternativa, sino porque con la festividad varios miembros del equipo se han desvinculado del proyecto hasta los últimos días, haciendo que el riesgo activado se prolongase hasta casi al final del sprint.

  • Incapacidad de algún miembro del equipo

    • Activación del riesgo: el riesgo se activó el día 13/04, cuando comenzó la festividad de la Feria, ya que varios miembros del equipo quisieron disfrutar de las vacaciones.
    • Planes de contingencia aplicados:
      • Intentar minimizar el impacto con el trabajo de los demás integrantes. Para minimizar el impacto de la ausencia de varios miembros, otros miembros deberán avanzar en todas aquellas tareas que puedan hasta que los demás integrantes vuelvan.
    • Estado actual: mitigado (18/04). Con el avance de la semana, el equipo se puso las pilas para avanzar en el entregable.
    • Lecciones aprendidas: cuando haya alguna festividad cercana, es recomendable dejar la mayor parte del trabajo finalizado para evitar retrasos innecesarios en las tareas y que se desequilibren las tareas.
    • Eficiencia de los planes de contingencia: para este caso, el plan de contingencia ha funcionado a medias. Gracias a su aplicación han habido tareas que han avanzado, sin embargo, ha ocasionado que el tiempo invertido en la asignatura nuevamente sea desequilibrado.

  • Tecnología inadecuada al contexto de la aplicación

    • Activación del riesgo: el riesgo se activó el día 21/04 cuando el equipo trató de transformar la página a HTTPS pero fallaban elementos del proyecto por ello.
    • Planes de contingencia aplicados:
      • Continuar con HTTP y encontrar una alternativa. Se debe estudiar el caso y analizar posibles alternativas para que funcione la aplicación en HTTPS.
    • Estado actual: monitorizando. Todavía el riesgo no se ha mitigado.
    • Lecciones aprendidas: hay que estar atento en todo momento del diseño de la aplicación pues puede saltar un error de dependencia en cualquier momento.
    • Eficiencia de los planes de contingencia: en estudio.